Malicious code (malcode) may be inserted into software applications during the software development lifecycle (SDLC). Malcode includes computer viruses, exploits, worms, logic bombs, keyloggers, spyware, Trojan horses and the like. Malcode is used to disrupt computing device operations, repurpose or hijack computing devices, gather sensitive information, gain access to access-controlled systems, and the like. Similarly, malcode may also be designed to affect all or portions of a computer network, including coopting a network to further spread the malcode, gather sensitive information, and the like.
Sophisticated malcode attacks demonstrate the far-reaching consequences of these tactics. It is important to avoid or mitigate such attacks because software and electronically stored information plays a pervasive and crucial role in individuals personal lives, business, and in national security. Physical property can also be affected by malcode. For example, the Stuxnet computer worm was engineered to spread across computer networks and infiltrate and attack programmable logic controllers made by a specific company connected to specified motors used uranium enrichment in order to curtail weapon of mass destruction development programs in rogue nations. This was the first widely reported instance of malcode destroying physical devices.
Software plays an increasingly important role in national security. For example, software supports defense communications and mission. Software controls the critical infrastructure and weapon systems that protect the homeland. Unfortunately, the mission-critical nature of this software has made it a target for attack. U.S. adversaries, including spies and terrorists, are constantly working to compromise defense systems and critical infrastructure software. A 2008 report from the U.S. Department of Defense has highlighted this risk, stating “High-end attackers will not be content to exploit opportunistic vulnerabilities, which might be fixed and therefore unavailable at a critical juncture. They may seek to implant vulnerability for later exploitation.
Substantial research and development has explored methods and technologies for preventing attacks on critical software systems. Prevention techniques include restricting access, proactively identifying network and application vulnerabilities, and monitoring both networks and applications to detect intrusions. While all of these techniques have been successful at reducing the threat of system compromise, they are ineffective when applied to an insider threat. An insider threat is any effort being performed in support of an adversarial mission or goal from within a trusted environment. What sets insider threats apart from other threats is the use of normal activities by adversaries to accomplish abnormal and malicious missions. Normal activities include supporting deployed software platforms and assisting in portions of the software development cycle. Many security defenses seek to identify adversaries by their abnormal tactics; therefore it is often difficult to detect insider threats with traditional approaches.
Identification of malcode when it is being inserted into software applications during the software development cycle stops malcode before it can be implemented or distributed. This minimizes and in most cases eliminates the potentially dangerous consequences the malcode is intended to implement because the malcode can be removed before the software is released “into the wild.” Furthermore, identification facilitates apprehending the individuals or groups who sought to implement the malcode in the first place. Compared to attempting to identify the person who implemented the malcode after the software has been released and the failures have been identified through experiencing the effects of the malcode, connecting the malcode to the individual who sought to implement is easier to facilitate when the malcode is quickly identified during development.
While some types of malware can be identified using off-the-shelf virus and malware detectors, malcode incorporated into source code during the software engineering process is far more difficult to detect. Sophisticated malcode, placed in source code, can look just like normal application logic when coded as part of the software development process. Likewise, malcode can be obfuscated effectively when crafted properly. Detailed, insider knowledge of an application and its environment can also help an adversary create malcode that is more difficult to detect and also more effective than generic malware.
Current approaches that attempt to identify malcode during development rely on techniques borrowed from generic software security analysis, namely: examining coding constructs for suspicious functionality, analyzing structural characteristics of binary code, or security testing for vulnerabilities. These techniques may be applied to detect malcode during software development but the solutions are not specific to insider threats or the detection of malcode created within otherwise legitimate software. Many of the current techniques have a significant number of false positives, due to the difficulty in distinguishing between legitimate functionality and malicious code. Further, due to an adversary's ability to obfuscate their intent, such techniques are prone to returning a significant number of false negatives, failing to detect the presence of malcode. Furthermore, malicious code can often appear to be a mistake, providing malicious insiders with plausible deniability when the malcode is discovered.
Given the foregoing, facilitating identification of malcode inserted during the software development cycle is needed. In particular, reductions of false negatives and false positives and detection of malcode created within otherwise legitimate software is desired. Further, what is needed are ways of facilitating identification of malcode insertion by insiders.